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L'invention concerne un procede de pilotage a distance d'une station 
d'utilisateur munie d'un lecteur de carte a puce via un reseau de type Internet. 

L'invention concerne egalement une architecture permettant la mise en 
ceuvre d'un tel procede. 
5 L'invention s'applique notamment a un demonstrateur de carte a puce. 

Dans le cadre de l'invention, le terme "station d'utilisateur" doit etre 
compris dans un sens general. La station precitee peut etre notamment 
constitute par un ordinateur personnel fonctionnant sous divers systemes 
d'exploitation, tels WINDOWS ou UNIX (tous deux etant des marques 
10 deposees). Elle peut etre aussi constitute par une station de travail, un 
ordinateur portable ou un terminal de carte, dit dedie. Dans ce qui suit, une telle 
station d'utilisateur sera appelee simplement "terminal". 

De meme, dans le cadre de l'invention, le terme "reseau Internet" 
englobe, outre le reseau Internet proprement dit, les reseaux prives 
15 d'entreprises ou similaires, dits "intranet", et les reseaux les prolongeant vers 
I'exterieur, dits "extranet". 

Les cartes a puce sont utilisees dans divers domaines : applications 
bancaires, de sante, comme "porte-monnaie" dit electronique, etc. Sur une carte 
a puce peuvent en outre coexister plusieurs applications (carte a puce multi- 
20 application). 

Lorsqu'une nouvelle application est rendue disponible sur une carte a 
puce, il est souhaitable de pouvoir disposer de terminaux, dedies ou non, pour 
organiser des seances de formation, notamment pour presenter les 
fonctionnalites de cette carte et ses possibilites. Ces seances de formation ou 
25 de presentation peuvent s'adresser a des publics tres divers : personnel de 
maintenance, vendeurs, voire usagers finaux. Le contenu pedagogique et la 
forme des prestations a fournir doivent en general etre adaptes au public vise. 

Dans Tart connu, les solutions traditionnellement propos6es pour la 
realisation d'une station de demonstration de carte a puce, que Ton appellera ci- 
30 apres simplement "demonstrateur", font appel a une configuration a base 
d'ordinateur individuel et a des programmes specifiques de pilotage du terminal 
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et de son lecteur de carte a puce. Ces programmes sont le plus souvent ecrits 
dans un langage du type Basic, C++ ou JAVA (marques deposees). 

Cette solution, si elle ne necessite pas generalement un materiel 
particulierement couteux (simple ordinateur individuel), n'est pas pour autant 
5 exempte d'inconvenients et parmi lesquels les suivants : 

- les programmes specifiques precites sont le plus souvent volumineux ; 

- leur mise en place est egalement longue et complexe ; 

- il est necessaire de sauvegarder les programmes nouvellement 
implantes dans la machine et, lors de la premiere mise en place, si la machine 

10 . ne comporte pas de programme permettant une sauvegarde sur un peripherique 
specialise, type "IOMEGA" (marque deposee) ou similaire, il est necessaire de 
surplus d'implanter un tel programme ; 

- pour chaque mise £ jour de ('application enregistf§e sur la carte a 
puce ou lorsque le contenu de la demonstration est different (adaptation au 

15 public concerne par exemple), il est necessaire de reiterer les processus 
rappelestci-dessus ; et - 

- pour les operateurs, rapprentissage du mode operatoire d'un logiciel 
ecrit dans les langages rappeles ci-dessus demande du temps, car leurs 
interfaces graphiques-ne sont pas normalisees : les operateurs doivent done 

20 etre specialises, ce qui peut entrainer des couts supplementaires. 

On doit ajouter que, si plusieurs terminaux sont utilises aux fins de 
demonstration, les inconvenients precites se repetent pour chacun de ces 
terminaux : il est notamment necessaire de charger x fois le meme programme, 
si x est le nombre de terminaux, ces derniers pouvant etre tres eloignes les uns 

25 des autres. Meme si Ton recourt a des procedures de telechargement a partir 
d'un serveur central, il est quand meme necessaire de s'assurer que la version 
de logiciel presente dans tous les terminaux . est identique. Des procedures 
specifiquestd'ardministratiomsont doRic^neeessaiRies^ 

D'autre part, avec le developpement du reseau Internet, il serait 

30 souhaitable de pouvoir piloter a distance les terminaux de presentation, via 
precisement ce reseau et en faisant usage des protocoles de transmission 
standards utilises sur celui-ci. 



Des solutions de ce type ont ete proposees. Cepenclarit ces solutions 
ne sont pas non plus exemptes d'inconvenients. Elles necessitent en effet de 
telecharger ou d'implanter dans le terminal, pour chaque application de 
demonstration, une piece de logiciel specifique connue sous I'appellation anglo- 

5 saxonne "plug-in", generalement ecrite en langage C ou C++, pour que ce 
terminal puisse communiquer avec la carte a puce, via un lecteur de carte a 
puce. Les pieces de logiciels precitees souffrent des memes defauts que ceux 
evoques ci-dessus : code volumineux qu'il faut installer ou telecharger avant 
chaque demonstration, interfaces graphiques non normalisees, etc. Comme 

10 precedemment, il n'est pas en effet possible d'installer une fois pour toutes un 
"plug-in", car celui-ci depend notamment, outre du type de navigateur utilise, de 
I'application en demonstration et de la version des programmes de pilotage. 

L'invention, tout en remplissant les besoins qui se font sentir, vise a 
pallier les inconvenients des procedes et dispositifs de Tart connu, et dont 

15 certains viennent d'etre rappeles. 

L'invention se fixe pour but un procede et une architecture de systeme 
permettant de piloter un terminal muni d'un lecteur de carte a puce et connecte 
de fagon classique a un reseau de type Internet, notamment en vu de realiser 
des demonstrations d'au moins une application enregistree dans la carte a 

20 puce. 

Pour ce faire, selon une caracteristique essentielle de l'invention, le 
logiciel de pilotage specifique a chacune des applications de demonstration est 
heberge par un serveur eloigne de type "WEB" connecte, egalement de fagon 
classique, au reseau Internet. Le terminal, pour sa part, est muni d'une pi£ce de 

25 logiciel particulier que Ton denommera ci-apres "specialise". Dans le contexte 
de Tinvention, le terme "specialise" utilise pour cette piece de logiciel signifie 
seulement qu'il s'agit d'une piece de logiciel non standard qui doit etre 
implantee dans le terminal, mais en aucun cas qu'elle est specifique a 
Tapplication en cours de demonstration. Tout au contraire cette piece de 

30 logiciel, d'un point de vue "application", est entierement generique et est 
independante de celle-ci, quelle qu'elle soit. 
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En outre, selon une autre caracteristique importante, la taille cle la 
piece de logiciel necessaire peut etre tres reduite, pour des raisons liees a la 
nature des fonctions qui lui sont devolues et qui seront explicitees ci-apres. De 
ce fait, elle peut etre implantee une fois pour toutes dans le terminal et y resider 
5 a demeure, sans alterer de fa?on significative les ressources informatiques 
propres au terminal, notamment sa capacite de memoire, en particulier si celui- 
ci est utilise pour d'autres taches. 

^invention presente done de nombreux avantages, et notamment les 
suivants : 

10 - une mise a jour simplifiee des demonstrations, puisque seuls les 

programmes heberges par le serveur distant doivent etre modifies : aucune 
intervention specifique sur les terminaux n'est plus necessaire ; 

- une configuration rapide et simple du terminal, qui peut etre un micro- 
ordinateur de type standard, muni d'un navigateur qui peut j egalement etre d'un 

15 type courant du commerce, souvent pre-installe f nce pour, les memes raisons 
que celles precedemment rappelees»Er (les^ % doranees^ * specifiques a la 
demonstration proprement dite etant localisees dans le serveur) ; 

- Tinterface graphique est standardisee egalement puisque fournie par 
le navigateur dont^les- caraeteristiques^eWe -made operatoire sont familiers a 

20 Toperateur du terminal, meme si celui-ci n'a pas de connaissances particulieres 
en programmation ou en informatique ; et 

- le surcout et I'augmentation de la complexite dus aux dispositions 
specifiques a Tinvention sont negligeables puisque reduits a la seule 
implantation d'une piece de logiciel specialise, de taille reduite, implantation qui 

25 peut d'ailleurs, dans certaines circonstances, etre realisee une fois pour toute. 

II s'ensuit que le systeme presente une grande universality puisque 
que le terminal peut virtuellement effectuer toutes les demonstrations d'une 
entreprise ou. d'une societerce quleile -que^soit Ja carte a puce^a presenter, a la 
seule condition que cette derniere soit d'un type normalisee pour etre 

30 compatible avec le terminal, ce qui en soi sort du cadre strict de Tinvention. Le 
systeme autorise egalement une grande fiabilite. 
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[.'invention a done pour objet principal un procede de pilotage a 
distance d'une station d'utilisateur via un reseau de type Internet, ladite station 
d'utilisateur etant munie d'un lecteur de carte a puce et comprenant une 
premiere pile protocolaire de communication, ledit lecteur de carte a puce 
5 comprenant une deuxieme pile protocolaire de communication et ladite carte a 
puce comprenant une troisieme pile protocolaire de communication, permettant, 
d'une part, des communications entre ladite station d'utilisateur et un serveur 
eloigne connecte au dit reseau et, d'autre part, des communications entre ladite 
station d'utilisateur et ladite carte a puce via ledit lecteur de carte a puce, ladite 
10 station d'utilisateur comprenant en outre des moyens de generation de requetes 
transmises au dit serveur eloigne, caracterise en ce qu'il comprend : 

- une premiere phase preliminaire de memorisation dans ledit serveur 
eloigne de donnees et/ou instructions permettant I'elaboration de 
commandes specifiques sur reception de requetes specifiques 

15 provenant desdits moyens de generation de requetes et leur 

transmission a ladite station d'utilisateur ; 

- une deuxieme phase preliminaire de chargement dans ladite station 
d'utilisateur d'une piece de logiciel specialise formant interface entre 
lesdites premiere et deuxieme piles protocolaires, et destinee a traduire 

20 lesdites commandes specifiques revues par ladite station d'utilisateur en 

des commandes conformes a un premier protocole de communication 
determine ; 

- et au moins les etapes suivantes : 

a/ transmission au dit serveur eloigne d'au moins une requete 

25 specifique ; 

b/ generation par ledit serveur eloigne, sur reception d'une telle 
requete, d'au moins une desdites commandes specifiques et leur 
transmission a ladite station d'utilisateur selon un deuxieme protocole 
de communication determine ; 

30 ol reception de cette commande specifique a ladite station 

d'utilisateur, interception par ladite piece de logiciel specialise et 
traduction dans ledit premier protocole de communication determine ; 



d/ transmission de ladite commande traduite a ladite carte a puce 
selon ledit premier protocole de communication determine via ledit 
lecteur de carte a puce; et 

el activation par ladite commande traduite d'au moins une fonction 
determinee d'au moins une application enregistree dans ladite carte a 
puce, de maniere a realiser ledit pilotage. 
U invention a encore pour objet une architecture de systeme pour la 
mise en oeuvre de ce precede. 

L'invention s'applique plus particulierement a Tapplication du procede et 
de Tarchitecture de systeme a un demonstrateur de carte a puce. 

L'invention va maintenant etre decrite de fa?on plus detaillee en se 
referant aux dessins annexes, parmi lesquels : 

la figure 1 il lustre schematiquement un exemple d'architecture de 
systeme d'application a base de carte a puce selon l'art connu ; 

la figure 2 illustre de fagon plus detaillee I'architecture logique d'un 
tel systeme y et * 

la figure 3 illustre un exemple ^'architecture pour le pilotage a 
distance d'un systeme d'application a base de carte a puce selon 
Tinvention. 

Dans ce qui suit, sans en limiter en quoi que ce soit sa portee, on se 
placera ci-apres dans le cadre de Tapplication preferee de Tinvention, sauf 
mention contraire, e'est-a-dire I'application a un demonstrateur de carte a puce. 

On va tout d'abord rappeler brievement les caracteristiques techniques 
essentielles d'un systeme d'application a base de carte a puce. Celui-ci 
comporte generalement les elements principaux suivants : 
une carte a puce ; 

un systeme hote constituant le terminal precite ; 

un - reseaui ,de> communication, a sa^pirb le reseau^ Internet dans 
Tapplication preferee ; 

et un serveur d'application connecte au reseau Internet. 
La figure 1 illustre schematiquement un exemple d'architecture de ce 
type. Le terminal 1 , par exemple un ordinateur individuel, comporte un lecteur 3 



de carte a puce 2. Ce lecteur 3 peut etre ou non physiquement integre dans le 
terminal 1. La carte a puce 2 comporte un circuit integre 20 dont des connexions 
d'entrees-sorties affleurent en surface de son support pour autoriser une 
alimentation en energie electrique et des communications avec le terminal 1. Ce 
5 dernier comprend des circuits d'acces 11 au reseau Internet. II peut s'agir d'un 
modem pour se connecter a une ligne telephonique commutee ou a un reseau 
numerique a integration de services ("RNIS"), via par exemple un prestataire de 
services Internet ("Internet Service Provider" ou "ISP", selon la terminologie 
anglo-saxonne). 

10 Le terminal 1 comprend naturellement tous les circuits et organes 

necessaires a son bon fonctionnement, et qui n'ont pas ete representes dans un 
but de simplification du dessin : unite centrale, memoires vive et fixe, memoire 
de masse a disques magnetiques, lecteur de disquette et/ou de CedeRom, etc. 

Habituellement, le terminal 1 est aussi relie a des peripheriques 

15 classiques, integres ou non, tels un ecran de visualisation 5, un clavier 6 et un 
pointeur 7, par exemple de type souris. 

Dans le cadre de Tinvention, c'est grace notamment a la cooperation de 
ces terminaux que la demonstration pourra etre conduite. 

Le terminal 1 peut etre mis en communication avec des serveurs 

20 connectes au reseau RI, dont un seul, 4, est illustre sur la figure 1. Les circuits 
d'acces 11 mettent le terminal 1 en communication avec les serveurs 4 grace a 
un logiciel particulier 10, appele navigateur, ou "browser" selon la terminologie 
anglo-saxonne. Celui-ci permet d'acceder a diverses applications reparties sur 
I'ensemble du reseau /?/, generalement selon un mode "client-serveur". 

25 Habituellement, les communications sur les reseaux s'effectuent 

conformement a des protocoles repondant a des standards comprenant 
plusieurs couches logicielles superposees. Dans le cas d'un reseau Rl de type 
Internet, les communications s'effectuent selon des protocoles sp§cifiques a ce 
type de communication, mais qui comprennent aussi plusieurs couches 

30 logicielles. Le protocole de communication est choisi en fonction de I'application 
plus particulierement visee : interrogation de pages ,HI WEB"", transferts de 
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fichiers, courrier electronique (e-mel, ou "e-mail" selon la terminologie anglo- 
saxonne), forums ou "news' 1 , etc. 

Uarchitecture des reseaux de communication est decrite par diverses 
couches. A titre d'exemple, le standard "OSI" ("Open System Interconnection"), 

s defini par ¥ "ISO", comporte sept couches qui vont des couches dites basses 
(par exemple la couche dite "physique" qui concerne le support de transmission 
physique) aux couches dites hautes (par exemple la couche dite "d'application"), 
en passant par des couches intermediates, notamment la couche dite de 
"transport". Une couche donnee offre ses services a la couche qui lui est 

10 immediatement superieure et requiert de la couche qui lui est immediatement 
inferieure d'autres services, via des interfaces appropriees. Les couches 
communiquent a I'aide de primitives. Elles peuvent egalement communiquer 
avec des -couches de meme niveau. Dans certaines architectures, Tune ou 
I'autre de ces couches peut etre inexistante. 

15 Dans un environnement Internet, les couches sont au nombre de cinq, 

et de.fagon plus precise, en allant de la .couche -superieure a la couche 
inferieure i la ^couche ^'applications ("http", "ftp", "e-mail", etc.), la couche de 
transport ("TCP"), la couche d'adressage de reseau ("IP"), la couche de liens de 
donnees-("PPP^ "Slip", ete^et la couche physique. 

20 On va maintenant decrire, de fagon plus detaillee, un exemple 

^architecture typique pour un systeme d'application a base de carte a puce 
selon Tart connu, par reference a la figure 2. Sur cette figure, on a decrit plus 
particulierement I'architecture logique en couches. 

Le terminal 1 comprend les circuits 1 1 d'acces au reseau Rl qui 

25 regroupent les couches logicielles inferieures Ci et C2, correspondant aux 
couches "physique" et de "lien de donnees" precitees. 

On a egalement represents les couches superieures C3 et C4, 
corresporndarnt^aux^couchesrfd'a^nessage^ reseauiL ("IP") et^de ^"transport" 
('TCP"). La couche superieure duplication ("http", "ftp", "e-mail", etc.) est 

30 schematisee par un navigateur "WEB" 10 de type quelconque, de preference de 
type standard du commerce. 



L'interface entre les couches inferieures, Ci et C2, et les couches 
superieures, C3 et C4, est constitute par une couche logicielle 15 generalement 
appelee "driver couches basses' 1 . Les couches superieures, C3 et C4, 
s'appuient sur cette interface et sont mises en oeuvre par I'intermediaire de 
bibliotheques de fonctions specifiques ou bibliotheques reseau 14, avec 
lesquelles elles correspondent. Dans le cas du reseau Internet, 'TCP/IP" est mis 
en oeuvre au moyen de bibliotheques dites de "sockets". 

Cette organisation permet au navigateur 10 de poser des requetes vers 
un serveur eloigne 4, pour la consultation de pages "WEB" (protocole "HTTP"), 
pour le transfert de fichiers (protocole "FTP") ou I'envoi de courrier electronique 
(protocole "e-mail' 1 ). 

Le terminal 1 comprend egalement le lecteur de carte 3, integre ou non. 
Pour communiquer avec la carte a puce 2, le lecteur de carte englobe 
egalement deux couches basses, CC1 (couche physique) et CC2 (couche de 
lien de donnees), jouant un role similaire aux couches C1 et C2- Les interfaces 
logicielles avec les couches CC1 et CC2 sont decrites, par exemple, par la 
specification "PC/SC" ( M part6 t service provider"). Les couches elles-memes, 
CC1 et CC2, sont notamment decrites par les normes ISO 7816-1 a 7816-4. 

Une couche logicielle supplementaire 13 forme interface entre des 
couches applicatives, sous la reference unique 16, et les couches inferieures, 
CC1 et CC2. La fonction principale devolue a cette couche 13 est une fonction 
de rnultiplexage/demultiplexage. 

L'architecture du terminal 1 decrite jusqu'a present est entierement 
commune a Tart connu. On a egalement represents sur la figure 2, en traits 
discontinus, un element supplementaire 8, que Ton appellera "module 
specialise" et qui est specifique a Tinvention. Ce module 8 est dispose entre la 
couche C4 et Tinterface 13. La fonction de ce module sera explicitee ci-apres. 

Du cote de la carte a puce 2, on retrouve une organisation similaire a 
celle du terminal 1, a savoir la presence de deux couches basses, r6ferencees 
CC'1 (couche physique) et CC'2 (couche de lien de donnees), ainsi qu'une 
couche ^interface 23, tout a fait similaire a la couche 13. Cette couche 23 



assure une interface entre tes couches protocolaires CC'1 et CC'2 precitees et 
une ou plusieurs couches applicatives, representees sous la forme d'un module 
unique reference 26. 

Les communications entre le terminal 1 et la carte a puce 2 s'effectuent 
5 a Paide de commandes standardises. 

Differents protocoles sont utilisables, et a titre d'exemples non 
exhaustifs les suivants : 

la recommandation ETSI GSM 11.11 ; 

le protocole defini par la norme ISO 7816-3, en mode caractere T=0 ; 
10 - le protocole defini par la norme ISO 7816-3, en mode bloc T=1 ; 

ou le protocole defini par la norme ISO 3309, en mode trame "HDLC" 
(pour M High-Level Data Link Control procedure" ou procedure de commande 
de liaison a haut niveau). 

Dans le cadre de I'invention, on utilisera de preference le protocole ISO 
15 7816-3, en mode bloc. 

De fa^on connue en soi, a chaque couche de protocole il est associe un 
certain nombre de primitives qui permettent les echanges de donnees entre 
couches de meme niveau et d'une couche a Pautre. 

Dans Petat-actuel de la technique, il n'est pas possible de mettre en 
20 communication directe la carte a puce avec un serveur eloigne 4, via le reseau 
Internet RL Aussi, comme il a ete rappele, pour effectuer une demonstration 
d'une ou plusieurs applications enregistrees de la carte a puce 2, il a ete 
propose dans Part connu, soit d'implementer dans le terminal 1 des logiciels 
specifiques, soit de les telecharger a partir d'un serveur eloigne, sous la forme 
25 de "plug-ins". Ces solutions presentent de nombreux inconvenients, qui ont ete 
egalement rappeles. 

On va maintenant decrire une architecture de systeme conforme a 
Pinventiom et permettant de, pall ier«ces*inconveniemts; par reference a la figure 3. 
A Pexception de dispositions specifiques a P invention, Parchitecture 
30 presentee sur la figure 3 reprend Tessentiel de la configuration materielle et 
logique des figures 1 et 2. Aussi, il n f a ete represents sur cette figure que les 
elements indispensables a la bonne comprehension de Pinvention. En outre, les 
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elements communs a ces figures portent les memes references et ne seront re- 
decrits qu'en tant que de besoin. 

On doit bien comprendre egalement que la carte a puce 2 ne necessite 
aucune adaptation. Les communications entre le terminal 1 et celle-ci 
s'effectuent, comme dans I'art connu, en utilisant les jeux de commandes 
normalisees qui viennent d'etre decrits succinctement. 

Aussi, dans un but de simplification du dessin, les differentes couches 
protocolaires de communication, en soi communes a I'art connu, n'ont pas ete 
representees. 

Selon une premiere caracteristique importante de I'invention, I'essentiel 
des informations et codes necessaires pour effectuer une demonstration d'une 
carte a puce particuliere, et de facon plus generate pour piloter une telle carte a 
puce, est localise, non plus dans le terminal 1 , sous quelque forme que ce soit 
(programme ou "plug-ins" specifiques telecharges), mais dans le serveur 
eloigne 4. 

Selon une deuxieme caracteristique importante de I'invention, on prevoit 
un module specialise 8 dans le terminal 1 . Cependant, il doit etre bien compris 
que le terme "specialise" a une signification particuliere dans le cadre de 
I'invention. Ce module 8 est dispose entre la couche C4 de la pile protocolaire 
du terminal 1 et I'interface 13 (voir figure 2), comme il a ete precedemment 
indique. II est constitue avantageusement d'une piece de logiciel et a pour 
fonctions essentielles de realiser une interface entre le reseau Internet Rl et le 
lecteur de carte a puce 3, d'une part, et de traduire des commandes regues du 
serveur 4, via le reseau Internet Rl, en commandes normalisees conformes aux 
normes ISO precitees. En ce sens, le module 8 est "generique" par nature, car 
entierement independant de I'application ou des applications enregistrees sur la 
carte a puce 2. En outre, du fait des fonctions qui lui sont devolues, la quantite 
de code necessaire est tres reduite en pratique. 

De facon plus detaillee, le serveur eloigne 4 comprend, par exemple, 
outre des moyens de traitement de donnees informatises classiques (non 
representes), un serveur "HTTP" 40 proprement dit et des organes de 
memorisation, 41 et 42, que Ton a representes arbitrairement distincts. 
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Un premier organe de memorisation 41 permet de stacker des feuilles 
d'affichage, que Ton appellera "statiques", par exemple dans un format de type 
"HTML" ou autres ("XML", eta). 

Le second organe de memorisation, reference 42, est destine plus 
particulierement a stacker des donnees representant les contextes de la ou des 
cartes a puce objet(s) d'une demonstration. Un "contexte carte a puce" est une 
representation en memoire de la carte a puce 2 au niveau du serveur eloigne 4. 
Le contexte carte a puce comprend par exemple le numero de version du 
systeme Sexploitation commandant la carte a puce ou "operating system" selon 
la terminologie anglo-saxonne. L'organe de memorisation 42 permet de stacker 
egalement des donnees ou instructions permettant d'elaborer un jeu de 
commandes specifiques necessaires aux demonstrations precitees de carte a 
puce 2. Ces commandes specifiques vont etre interceptees par le module 
specialise 8 eMraduites, de fa<?on a pouvoir etre comprises par Ja carte a puce 2 
lorsqu'elles luLseront transmises. 

Les prinGip^les^BtapMS^du^pnoeede^selon Tin vent iomi^sont decrites ci- 

apres. 

De fagon classique en soi r le terminal permet notarnment de mettre la 
carte a puce-sous tension, via ile lecteur de carte a puce.3, et, de fagon plus 
generale, de I'initiaiiser. De fagon plus precise, c'est le module specialise 8 qui 
met la carte a puce 2 sous tension, par I'intermediaire d'un script execute dans 
le serveur eloigne 4. Le navigateur 'WEB" 10 permet, egalement de fagon 
classique, de poser des requetes vers le serveur eloigne 4, via un modem 1 1 ou 
un organe similaire, un canal classique de transmission 100 (ligne telephonique 
ou autre) et le reseau Internet RL Le chemin de transmission passe 
habituellement par un prestataire de service, eventuellement un M coupe-feu M 
("firewall") et/ou un systeme dit "proxy" (non represents). A titre d'exemple, la 
requete-posee^permetd'affi^ sur Tecran 5 

et, ensuite, de naviguer dans ce site, par affichages successifs de pages, selon 
les options presentees. 

La requete transmise au serveur eloigne 4 peut permettre egalement 
d'afficher des pages en langage "HTML" relatives a la carte a puce 2, pages 
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associees a la demonstration en cours et stockees dans I'organe de 
memorisation 41. 

De fagon plus particuliere a ('invention, la requete transmise au serveur 
eloigne 4 a pour resultat la generation par celui-ci d'un jeu de commandes 
specifiques destinees a la manipulation de la carte a puce 2 en cours de 
demonstration. 

En effet, certaines requetes specifiques sont reconnues comme telles 
par le serveur 40 et sont traitees dans le cadre du contexte de la carte a puce 
en memoire dans I'organe 42. II est a noter que le contexte de la carte a puce 2 
est mis a jour, par exemple lors de la mise sous tension de la carte a puce 2, par 
utilisation du signal dit de "RESET" de cette derniere. 

De fagon classique en soi, ['elaboration des commandes generees par 
le serveur 40 peut etre le resultat de I'execution d'un script de type "CGI" (pour 
"Common Gate Interface"). II s'agit d'un processus bien connu de I'Homme de 
metier dans le domaine des communications de type "client-serveur" sur le 
reseau Internet. A titre d'exemple, lorsqu'une requete de type formulaire est 
transmise a un serveur "WEB", celle-ci est transmise via une "passerelle" a un 
repertoire habituellement appele "cgi-bin" dans lequel sont enregistres des 
scripts. Les donnees resultats de I'execution d'un script particulier sont 
retransmises par le chemin inverse et envoyees au "client" ayant emis la 
requete, en I'occurrence sous forme de commandes specifiques transmises au 
terminal 1. 

Cependant, comme il a ete rappele, la carte a puce 2 ne peut pas 
communiquer directement avec le reseau Internet Rl et, en particulier, ne peut 
done pas recevoir, ni a fortiori interpreter les commandes emises par le serveur 
40. Ces commandes sont transmises, de fagon habituelle dans des paquets, 
Tadresse "IP" de destination etant celle du terminal 1, e'est-a-dire le "client". De 
meme, sauf a implanter un "plug-in" specialise dans le navigateur 10, ce dernier 
ne peut pas communiquer directement avec la carte a puce 2. 

Le module specialise 8 forme interface, par un premier cote, avec les 
couches protocolaires hautes du terminal 1 , e'est-a-dire C4 (voir figure 2). Les 
commandes specifiques regues par le terminal 1 sont interceptees et 
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"comprises" par le module 8 comme lui etant destinees. Selon Tun des 
caracteristiques essentielles de I'invention, ce dernier les traduit en un jeu de 
commandes conforme aux normes ISO precitees. Les autres commandes 
revues ne sont pas traitees par ce module 8 et transmises, de fagon classique, 
au navigateur 10. Le serveur 4 dispose d'une connexion distincte 80 avec le 
module specialise 8. Cette connexion peut etre securisee et supporter un 
chiffrage du type dit "SSL" (pour "Secure Socket Layer"). 

De fa^on schematique, pour mieux mettre en evidence le processus 
propre a I'invention, on a illustre la communication qui s'etablit entre le reseau 
Internet et le module 8 par un canal separe 80, represents en traits pointilles. 
Cependant, on doit bien comprendre que toutes les communications passent 
par les canaux de transmission habitue Is, et s'effectuent selon des protocoles 
de transmission normalises (par exemple "TCP/IP" pour le module specialise 8 
et "HTTP" pour le navigateur 10). 

Le module 8 forme egalement interface, par xin second cote, avec le 
lecteur de cartel puce 3. II transmettdomc^a celuUcides^ commandes qu'il a 
regues et traduitesr- Ces~ comma ndes^sont dechiffr6es:, si necessaires (si la 
liaison etait securisee)^et traduites. Elles*sont done desormais comprehensibles 
par la carte a puce 2. En. effet, .apres^traduction, les commandes retransmises a 
la carte a puce 2, via le lecteur 3, sont au format ISO 7816-4 et sont done 
compatibles avec le mode de communication utilise entre le lecteur de carte a 
puce 3 et la carte a puce 2. 

Les commandes ainsi transmises a la carte a puce 2 permettent, par 
exemple, une mise sous-tension de la carte a puce 2, d'activer la ou les 
applications memorisees dans celle-ci, par exemple pour executer des fonctions 
particulieres et/ou lire des fichiers specifiques enregistres dans celle-ci. En 
retour, la carte a puce 2 transmet au module specialise 8, viable lecteur de carte 
a puce 3, des commandes et/ou instnuctions-qui permettront^ dans une etape 
ulterieure, I'affichage sur Tecran 5 de differentes donnees propres a la carte a 
puce 2 en cours de demonstration. Cependant, ces commandes et/ou 
instructions sont tout d'abord traduites par le module specialise 8, transmise au 
serveur 4, et retransmises au terminal 1 et au navigateur 10. 
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Le module specialise 8 est un serveur de type 'TCP/IP" qui re$oit des 
requetes "TCP/IP" en provenance d'un script execute dans le serveur 40. La 
communication avec le module specialise 8 s'insere dans une requete entre le 
navigateur 10 et le serveur 40. Ce script est charge d'executer une succession 
de commandes a destination du module specialise 8. Ce dernier agit alors 
comme un serveur 'TCP/IP" et renvoie une reponse pour chaque commande 
•TCP/IP" regue du serveur 40. Le script precite, qui peut faire appel a un 
processus du type dit "CGI" (pour "Common Gate Interface") ou "Servlet Java" 
(marque deposee), traite I'ensemble des reponses "TCP/IP" du module 
specialise 8. Ensuite, il formate une reponse de type "HTTP" transmise au 
navigateur 10. Ainsi un utilisateur (non represents), par exemple le proprietaire 
de la carte a puce 2, peut interagir avec cette carte a puce 2 par I'intermediaire 
du navigateur 10, de scripts associes au serveur 40, du module specialise 8 et 
du fecteur de la carte a puce 3. 

Le navigateur 10 permet de visualiser le contenu de ia carte a puce 2. 

On constate done que la carte a puce 2 est en realite pilotee 
directement par un processus du type "CGI" et un contexte carte memorise dans 
le serveur 4. Tout se passe done comme si la carte a puce 2 etait en 
communication directe avec ce dernier et recevait des requetes du reseau 
Internet Rl. 

Pour fixer les idees, pour effectuer les taches qui lui sont devolues, le 
module 8 a une taille typique de 50 KO. II peut etre charge dans les moyens de 
memorisation (non represents) dont est pourvu le terminal 1, avant le debut 
d'une demonstration, de fa?on tres rapide compte tenu de sa tres faible taille, a 
Paide d'une disquette par exemple, ou a partir de tout autre support 
d'enregistrement. Mais il peut etre aussi etre laisse a demeure sans 
inconvenients, apres un chargement initial, ce pour la meme raison et sans 
oberer de fagon significative les ressources du terminal, notamment les 
ressources memoires de celui-ci. Toujours du fait de sa faible taille, il est 
egalement possible de le telecharger a partir du serveur eloigne 4, ou de tout 
autre serveur "WEB". Avec les technologies actuelles, meme en utiiisant une 
simple ligne telephonique de type commute, en ayant recours a un modem 
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rapide (56 K), le telechargement d'un programme de cette taille ne necessite 
que quelques dizaines de secondes. Cette methode presente Tavantage, de 
toujours disposer de la demiere version du programme specialise disponible, 
constituant le module 8. 

On constate aisement qu'it n'est pas necessaire que Toperateur possede 
des connaissances particulieres en programmation. [.'interface graphique, qui 
est celle du navigateur "WEB" 10, qui peut etre avantageusement d'un type bien 
connu du commerce, lui est tout a fait familiere. II lui suffit de connaltre I'adresse 
Internet du site "WEB" sur lequel il doit se connecter, adresse qui peut etre mise 
au prealable en memoire du navigateur 10, dans une liste dite de "favoris" ou 
appellations similaires, generalement connues sous la terminologie anglo- 
saxonne de "bookmarks". 

Le serveur 4 pouvant stocker, comme il a ete indique, des pages dites 
statiques en langage "HTML", les differentes etapes de la demonstration a 
realiser peuvent etre affichees sous forme d'un menu constitue d'hyperliens, 
Toperateur selectionnant Tune ou Tautre des options presentees, a I'aide du 
clavier 6, ou en cliquant dessus a Taide de la souris 7. 

Cependant, pour faciliter encore plus le deroulement de la 
demonstration, et I'automatiser d'avantage, il est egalement possible de 
telecharger, dans le navigateur 10, une appliquette, ou "applet" selon la 
terminologie anglo-saxonne, par exemple sous la forme d'une piece de logiciel 
en langage "JAVA" dont la taille est tres reduite. Cet "applet" permet de gerer le 
deroulement de la demonstration en transmettant les requetes necessaires au 
serveur 4, qui a son tour genere des commandes specifiques au module 
specialise 8, puis transmet le resultat de calculs qu'il effectue au navigateur 10, 
sous la forme d'une response "HTTP". Dans ce cas, I'essentiel du travail de 
Toperateur pourra se resumer a se connecter au serveur 4 et eventuellement, si 
besoin est, dans une phase initiale, a charger ou a telecharger, la piece de 
logiciel constituant le module specialise 8, apres avoir mis sous tension le 
terminal 1 et avoir introduit la carte a puce 2 dans le lecteur 3. 

A la lecture de ce qui precede, on constate aisement que Tinvention 
atteint bien les buts qu'elle s'est fixes. 
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La carte a puce ne necessite aucune adaptation. Le terminal de 
demonstration peut etre un micro-ordinateur du commerce ou un appareil 
similaire. II ne necessite pas non plus d'adaptation particuliere. La seule 
contrainte specifique a ['invention reste tres limitee : il est seulement necessaire 
5 de proceder au chargement, dans une phase preliminaire, d'une piece de 
logiciel de faible taille, piece de logiciel entierement independante de 
Tapplication ou des applications enregistrees sur la carte a puce en cours de 
demonstration. Comme il a ete indique, cette piece de logiciel peut etre chargee 
une fois pour toute. Elle peut etre egalement telechargee a partir du reseau 
10 Internet. II s'ensuit que la configuration d'une station de demonstration est 
reduite a sa plus simple expression et ne necessite aucune competence 
particuliere, ce qui contribue egalement a rendre le procede particulierement 
economique. 

L'interface graphique est familiere a tout operateur, puisqu'il s'agit de 
15 celle associe a un navigateur "WEB", qui peut etre avantageusement de type 
courant. 

Le procede permet une grande souplesse et une grande universalite. 
En effet, les donnees specifiques a une ou plusieurs demonstrations sont 
stockees dans un serveur eloigne et sont susceptibles d'etre utilisees par un 

20 grand nombre de stations. La mise a jour d'une demonstration donnee et/ou 
I'ajout d'une ou plusieurs demonstrations s'effectuent tres simplement, puisque 
seul le serveur eloigne stockant les donnees et les programmes necessaires a 
ces demonstrations est concerne. 

Le procede permet en outre un mode interactif entre des pages, par 

25 exemple de type "HTML", fournies par le serveur eloigne, et des informations et 
donnees provenant de la carte a puce, sous le controle de commandes et 
requetes provenant directement de ce meme serveur, et transmises apres 
traduction par la piece de logiciel specialisee a la carte a puce, via le lecteur. 

II doit etre clair cependant que ['invention n'est pas limitee aux seuls 

30 exemples de realisations explicitement decrits, notamment en relation avec 
Tarchitecture illustree par la figure 3. 
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Enfin, bien que le procede et I'architecture aient ete decrits cle fa?on 
detailiee dans le cas d'un demonstrateur de carte a puce, I'invention n'est en 
aucun cas limite a cette application particuliere. 

L'invention peuttrouver application a chaque fois que Ton desire piloter 
5 une station eornprenant un terminal et un lecteur de carte a puce^via le reseau 
Internet ou un reseau de type similaire : intranet, extranet. 
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REVENDICATIONS 

1 . Procede de pilotage a distance d'une station d'utilisateur via un reseau de 
type Internet, ladite station d'utilisateur etant munie d'un lecteur de carte a puce 
et comprenant une premiere pile protocolaire de communication, ledit lecteur de 
carte a puce comprenant une deuxieme pile protocolaire de communication et 
ladite carte a puce comprenant une troisieme pile protocolaire de 
communication, permettant, d'une part, des communications entre ladite station 
d'utilisateur et un serveur eloigne connecte au dit reseau et, d'autre part, des 
communications entre ladite station d'utilisateur et ladite carte a puce via ledit 
lecteur de carte a puce, ladite station d'utilisateur comprenant en outre des 
moyens de generation de requetes transmises au dit serveur eloigne, 
caracterise en ce qu'il comprend : 

- une premiere phase preliminaire de memorisation (42) dans ledit 
serveur eloigne (4) de donnees et/ou instructions permettant 
I'elaboration de commandes specifiques sur reception de requetes 
specifiques provenant desdits moyens de generation de requetes (10) et 
leur transmission a ladite station d'utilisateur (1) ; 

- une deuxieme phase preliminaire de chargement dans ladite station 
d'utilisateur (1) d'une piece de logiciel specialise (8) formant interface 
en t r e lesdites premiere et deuxieme piles protocolaires, et destinee a 
traduire lesdites commandes specifiques regues par ladite station 
d'utilisateur (1) en des commandes conformes a un premier protocole de 
communication determine ; 

- et au moins les etapes suivantes : 

a/ transmission au dit serveur eloigne d'au moins une requete 
specifique ; 

b/ generation par ledit serveur eloigne (4), sur reception d'un telle 
requete, d'au moins une desdites commandes specifiques et leur 
transmission a ladite station d'utilisateur (1) selon un deuxieme 
protocole de communication determine ; 
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c / reception de cette commande specifique a ladite station 
d'utilisateur (1), interception par ladite piece de logiciel specialise (8) 
et traduction dans ledit premier protocole de communication 
determine ; 

d/ transmission de ladite commande traduite a ladite carte a puce (2) 
selon ledit premier protocole de communication determine via ledit 
lecteur de carte a puce (3) ; et 

el activation par ladite commande traduite d'au moins une fonction 
determinee d'au moins une application (26) enregistree dans ladite 
carte a puce (2), de maniere a realiser ledit pilotage. 

2. Procede selon la revendication 1, caracterise en ce que lesdites donnees 
et/ou instructions memorisees dans ledit serveur eloigne (4) et permettant 
I'elaboration de commandes specifiques< comprennent des donnees dites de 
contexte de carte a puce, ledit contexte etant une representation, dans la 
memoire dudit serveur eloigne (4), de ladite carte a puce (2) presente dans 
ladite station d'utilisateur (1 ). 

3. Procede selon la revendication 2, caracterise en ce que ladite carte a puce 
(2) etant ^^commandee^par^un systeme d' exploitation associe^a un numero de 
version, ledit contexte comprend au moins ledit numero de version du systeme 
Sexploitation. 

4. Procede selon la revendication 1, caracterise en ce qu'il comprend en 
outre, suite a ladite etape d'activation, au moins : 

f/ une etape de transmission de donnees et/ou instructions entre 
ladite carte a puce (2) et ledit terminal (1), via ledit lecteur de carte a 
puce (3), ladite transmission s'effectuant selon ledit premier protocole 
de- communication determine ; 

g/ une etape de traduction desdites donnees et/ou instructions par 
ladite piece de logiciel specialise (8) et leur transmission vers ledit 
serveur eloigne (4), selon ledit deuxieme protocole de communication 
determine ; 
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hi une etape de traitement de ces donnees et/ou instructions par ledit 
serveur eloigne (4) ; 

i/ une etape d'elaboration par ce serveur (4) de donnees 
caracteristiques d'une configuration de ladite carte a puce (2) et/ou 
d'une application enregistree dans cette carte a puce (2) et de 
transmission desdites donnees caracteristiques audit terminal (1) 
suivant un troisieme protocole de communication determine ; et 
j/ une etape d'affichage, sur un ecran de visualisation (5) connecte au 
dit terminal (1), desdites donnees caracteristiques. 

5. Precede selon la revendication 4, caracterise en ce que lesdits moyens de 
generation de requetes etant constitues par un navigateur de type "WEB" (10), il 
comprend une troisieme phase preliminaire consistant a enregistrer dans ledit 
serveur eloigne (4) des donnees constituant des pages d'affichage dites 
statiques, et des etapes subsequentes comprenant la transmission, selon ledit 
troisieme protocole de communication determine, sur reception de requetes 
specifiques generees par ledit navigateur (10), de tout ou partie de ces donnees 
au dit terminal pour afficher des pages d'information associees a ladite carte a 
puce (2) sur ledit ecran de visualisation (5). 

6. Procede selon la revendication 5, caracterise en ce qu'il comprend une 
quatrieme phase preliminaire consistant a generer, a I'aide dudit navigateur 
(10), une requete particuliere transmise a un serveur eloigne connecte au dit 
reseau Internet (Rl), en vu de telecharger une piece particuliere de logiciel dite 
appliquette dans le navigateur (10), de maniere a automatiser tout ou partie 
desdites etapes a/ a j/. 

7. Procede selon la revendication 6, caracterise en ce que ladite appliquette 
est ecrite en langage "JAVA" (marque deposee). 

8. Procede selon la revendication 1, caracterise en ce que lesdites 
commandes specifiques sont le resultat de I'execution d'un script de type "CGI" 
dans ledit serveur eloigne (4). 
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9. Procede selon la revendication 1, caracterise en ce que ladite piece de 
logiciel specialise (8) est chargee dans ladite station d'utilisateur (1), pendant 
ladite premiere phase preliminaire, a partir d'un support d'enregistrement de 
donnees. 

5 10. Procede selon la revendication 1, caracterise en ce que ladite piece de 
logiciel specialise est telechargee dans ladite station d'utilisateur (1), pendant 
ladite premiere phase preliminaire, a partir d'un serveur eloigne, via ledit reseau 
Internet (Rl). 

11. Procede selon la revendication 1, caracterise en ce que ledit premier 
10 protocole de communication determine est du type "TCP/IP". 

12. Procede selon la revendication 1, caracterise en ce que ledit deuxieme 
protocole de communication determine est conforme aux normes ISO 7816-1 a 
7816-4. 

13. Procede selon la revendication- 4, caracterise- en ce que ledit troisieme 
15 protocole de communication determine est du type "HTTP". 

14. Architecture de systeme de pilotage a distance d'une station d'utilisateur 
(1) via un reseau de type Internet (Rl) t ladite station d'utilisateur (1) etant munie 
d'un lecteur de carte a puce (3), et comprenant une premiere pile protocolaire 
de communication, ledit lecteur de carte a puce (3) comprenant un deuxieme 

20 pile protocolaire de communication et ladite carte a puce (2) comprenant une 
troisieme pile protocolaire de communication, permettant, d'une part, des 
communications entre ladite station d'utilisateur (1) et un serveur eloigne (4) 
connecte au dit reseau et, d'autre part, des communications entre ladite station 
d'utilisateur (1) et ladite carte a puce (2) via ledit lecteur de carte a puce (3), 

25 ladite station d'utilisateur (1) comprenant en outre des moyens de generation 
de requetes (10) transmises au dit serveur eloigne (4), caracterisee en ce que 
ledit serveur eloigne (4) est muni de moyens de memorisation (41, 42) 
permettant le stockage de donnees et/ou instructions permettant I'elaboration de 
commandes specifiques sur reception de requetes specifiques provenant 
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desdits moyens de generation de requetes (10) et leur transmission a ladite 
station d'utilisateur (1) et en ce que ladite station d'utilisateur (1) est munie d'un 
module supplemental (8), dit specialise formant interface entre lesdites 
premiere et deuxieme piles protocolaires, et destine a traduire lesdites 

5 commandes specifiques revues par ladite station d'utilisateur (1), selon un 
premier protocole de communication determine, en des commandes conformes 
a un deuxieme protocole de communication determine, de maniere a les 
transmettre, selon ledit deuxieme protocole de communication determine, via 
ledit lecteur de carte a puce (3), a ladite carte a puce (2), pour activer au moins 

10 une fonction determinee d'au moins une application enregistree dans cette carte 
a puce (2). 

15. Architecture de systeme selon la revendication 14, caracterisee en ce que 
ledit serveur eloigne (4) comprend un serveur "HTTP" (40), des premiers 
moyens de memorisation (42) pour le stockage desdites donnees et/ou 

15 instructions permettant I'elaboration de commandes specifiques et des seconds 
moyens de moyens de memorisation (41) pour le stockage de donnees 
constituant des pages d'affichage en langage "HTML". 

16. Application de I'architecture systeme selon la revendication 14, a la 
realisation d'un demonstrates de carte a puce (2), ladite station d'utilisateur (1) 

20 comprenant un ecran de visualisation (5) pour I'affichage de donnees 
transmises par ledit serveur eloigne (4) audit module supplemental (8) et 
caracteristiques d'un contexte de ladite carte a puce (2), suivant un troisieme 
protocole de communication determine, lesdites donnees caracteristiques etant 
elaborees par ledit serveur eloigne (4) sur reception de donnees emises par 

25 ladite carte a puce (2), selon ledit deuxieme protocole de communication 
determine, traduites par ledit module supplemental (8) et transmises a ce 
serveur eloigne (4), selon ledit premier protocole de communication determine. 
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